![]() |
|||
![]()
|
![]() |
![]() Click Here! |
![]() |
NetView Management Services Although SNMP and other open network management standards continue to evolve, NetView remains the only way to provide comprehensive network management, control, and diagnosis of an SNA network. All SNA network nodes are inherently commandable from NetView and report all network management-related activities directly to NetView for processing by one of its function-specific applications. IBMs NetView support extends NetView management of the SNA network across the frame relay network to the end users controller. This support allows complete SNA network visibility and control with no remote-line and physical unit black holes, compatibility with existing NetView tools and applications, and virtually no operator retraining. Virtual Telecommunications Access Method (VTAM) Network Control Program (NCP) The VTAM Dynamic Reconfiguration (DR) facility supports the addition of NCP frame relay DLCIs. PVCs can be created or deleted without interrupting the frame relay network or regenerating NCP. Alternative Routing NCP provides alternative automatic routing by a private frame relay network if a primary (i.e., public) frame relay network becomes unavailable. Local Management Interface (LMI) A reserved link address (local DLCI) is used for communication between the FRAD and the frame relay network. The management interfaces are defined by ANSI T1.617-1991 Annex D and ITT Q.933 Annex A for DLCI 0. Users are able to specify either the ANSI or ITT LMI implementation as part of the configuration. This DLCI is used for communicating network resources (i.e., the list of valid DLCIs), determining the link status of each DLCI, and determining network status. The LMI DLCI cannot be used for data traffic. A status-inquiry message is used to query the status of the network. The status message is either a keep-alive message or a full-network status report. The status update message reports an unsolicited status change in a network component. Frame Relay Network Congestion The frame relay network provides notification of network congestion to end-user devices. Upon encountering congestion a frame relay switch provides forward notification of network congestion along the data route by setting the forward explicit congestion notification (FECN) bit in the frame relay header, as shown in Exhibit 4-2-6.
The network also notifies the sending node of congestion along the pvc by setting the backward explicit congestion notification (BECN) bit of packets going to the sender along the PVC. The bit is changed from 0 to 1 to indicate the presence of congestion. Network congestion is determined by a switch using the switchs queue length or buffer utilization. (See Exhibit 4-2-7.)
It is the function of the frame relay access node, or DTE device, to respond to the FECN and BECN bits. IBMs frame relay devices respond by controlling the transmit window size of devices transmitting on the congested DLCI. When a frame relay DTE receives notification of network congestion, it reduces its transmit window to 1. Once a network has indicated that it is returning to a normal state, the transmit windows are increased a frame at a time until they return to their normal transmit windows. Consolidate Link Layer Message (CLLM) If there are no frames returning to the sender, the end node can determine the presence of congestion over a DLCI through the CLLM information on the next query. The network is otherwise prohibited from notifying the sender of congestion on the DLCI. Discard Eligibility Bit Frame relay access nodes can mark frames for discard eligibility by the network as a means of reducing congestion during moderate traffic congestion periods. When the discard eligibility (DE) bit in a frame is set to 1, the user has indicated that the frame can be discarded if it encounters network congestion. The network sets the DE bit to 1 on data that follows on a physical link in excess of the CIR. Thus, the network can be divided into the following three zones:
SNMP Management Proliferation of LAN internetworks often leads to a separate management organization seeking a common management platform for multivendor equipment. Often the solution is SNMP. Most of IBMs frame relay products can be configured with an SNMP agent for management by IBMs NetView/6000 SNMP Manager. Support of concurrent SNMP and NetView enables each functional operations group, SNA and LAN internetwork, to execute their respective network management and control responsibilities through their management platform of choice. FRAME RELAY COMPARED TO ROUTER NETWORKS IBMs products transmit LAN, SNA, and APPN traffic across a frame relay WAN. The following section compares IBMs treatment of a frame relay WAN and the router approach. The major issues include:
Backbone The typical router backbone is a mesh of point-to-point links. In these networks, the router backbone is the network. The router is responsible for routing between end-user clients and application servers. Thus, routers are responsible for the definition and maintenance of network topology and the appropriate routing path for applications. Router networks may be referred to as administratively rich. In a frame relay backbone, by contrast, the network services are inherent in the frame relay service. Each frame relay access device provides application-transparent communication directly with its corresponding node across the network. This simplifies the configuration and administration of frame relay compared to a router-based network.
|
![]() |
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |